02. What is a User Story?

What is a User Story?

A user story is a short and concise feature description written from the user perspective. The template for writing a user story is :

** As a < type of user >, I want to < some goal > so that < some reason > **

• Refers to the person who wants the new capability. It is typically the end-user of the product but depending upon the product for which you are writing user stories, the end-user could be internal to the company such as customer service manager
• Captures the user's intent (or) need that they are trying to satisfy (or) job to be done. It does not cover details of 'how' the need is satisfied i.e doesn't refer to the UI design
• What is the reason or motivation behind the user's need (or) intent (or) job to be done? This conveys the benefit that the user gains when we help them achieve their goal or solve their problem.

Examples:

• As a fitness enthusiast, I want to create a custom workout so that I can use it to workout regularly to meet my specific fitness goal, exercise preferences, and body limitations.
• As an internal customer support manager, I want to view the custom workout of a specific user so that I can understand their issues better to assist in solving their problem.

For the Feature Review phase, the Product Requirements Document (PRD) captures the following key aspects of the initiative:

• scope of the initiative
• impact of initiative on product goals
• identifies the metricsidentifies the details of features at a high-level.

The Scrum team that is involved in developing and testing the product typically consults the product backlog that contains the prioritized list of features with detailed information.

Why do you need these features in the PRD?
It is critical for the feature details from the PRD to be broken down into manageable chunks that are clear, concise and written from a user perspective. This allows the development and QA team to collaborate with the Product Manager and Designer to discuss the details of how to support the feature based on the proposed design that was shared during project kick-off and updated based on feedback from stakeholders and feasibility input from the development team ( Refer to Coordination Activities Map in Lesson 1)

Who writes user stories?
Although user stories are mostly written by Product Manager, the scrum team members, and Product Designer can contribute to writing them as well. However, the Product Manager confirms the details of the user story and acceptance criteria (to be discussed soon) to ensure details are captured for the product backlog correctly. True to the definition of Agile-Scrum methodologies (discussed in Lesson 2), user stories are written and added to the product backlog throughout the feature development

A product has business-driven and system-level requirements that are not user-focused and seems like a misfit for the user-story format. In such scenarios, it is effective to write non-user stories that are simple and focus on detailing what needs to be done. For example:

• Track every single user interaction on every page at the browser and/or device level for Mixpanel tracking

Characteristics of a User Story

INDEPENDENT

Each story is self-contained and not dependent on another story

NEGOTIABLE

Focuses on capturing a user's needs without restricting how the user's needs are resolved

VALUABLE

Focuses on providing a clear value to the customer or end-user

Estimable

Can be costed during sprint planning to effectively fit into a sprint

SMALL

Can be developed and tested by the Scrum team

TESTABLE

Can be tested using the acceptance criteria and definition of done

Remember the mnemonic INVEST:
Independent
Negotiable
Valuable
Estimable
Small
Testable

QUESTION:

Write a User Story

Pick your favorite product’s feature and write a user story using the format we just learned.